home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / smaltalk / irc.lha / irc / st_irc3_3_92.txt < prev    next >
Text File  |  1993-07-24  |  30KB  |  717 lines
  1. *** this is a transcript of the Smalltalk meeting of March 3, 1992 ***
  2. *** this meeting took place on the Internet Relay Channel (irc)    ***
  3. *** I did a bit of editing, you may wish I had done more           ***
  4. *** mjb@netcom.com                                                 ***
  5.  
  6. <Ronalda> Go ahead Automan
  7. <automan> We at Cold Spring Harbor Laboratory are working on a rather large
  8. project
  9.  
  10. *** aknight has joined channel #Smalltalk
  11.  
  12. <automan> It involves the use of a database from Servio called Gemstone
  13. <mjb> (welcome aknight)
  14. <automan> We will be using Smalltalk to implement a Human genome mapping
  15. application
  16. <aknight> hello
  17.  
  18. *** tcl has joined channel #Smalltalk
  19.  
  20. <automan> What I am looking for are implementations of networks. Has aNYBODY
  21. <automan> Wupps.
  22. <Ronalda> Hello Allan.  I think I remember Peter and Danny introducing us once.
  23. <automan> Has anybody seen any code on implementing networks (the mathematical
  24. kind?)
  25. <mjb> welcome tcl 
  26. <aknight> Yes. I think so.  Why are you Ronalda?
  27.  
  28. *** khaw has joined channel #Smalltalk
  29.  
  30. <Ronalda> I've seend several.  Every one I've seen though would have been
  31. better done using the real objects of the problem domain.
  32. <Ronalda> Hi Mike!!
  33.  
  34. *** Signoff: khaw (Leaving)
  35.  
  36. <mjb> (welcome khaw) 
  37. <Ronalda> I'm Ronalda because my other choices for nicknames "Carl" and "Opus"
  38. were already taken.
  39. <automan> Well we want to use the networks to represent maps.
  40.  
  41. *** Ronalda is now known as Carl
  42. *** richard has joined channel #smalltalk
  43.  
  44. <mjb> welcome richard 
  45. <Carl> Hello Rich.  Is Adele going to join us?
  46. <richard> Adele will be here soon
  47.  
  48. *** Gregster has joined channel #Smalltalk
  49.  
  50. <Gregster> Hiya!
  51. <mjb> hi Gregster 
  52. <Gregster> Hey MJB!
  53.  
  54. <Carl> Back to the Networks problem.  Why not implement the objects in your
  55. real domain.  "Maps" or whatever you called them?
  56.  
  57. <mjb> *** quick 1 ? survey:  what ST is everyone using ****
  58. <richard>  ST V/
  59.  
  60. *** rayn has joined channel #Smalltalk
  61. *** Signoff: tcl (eff.org)
  62.  
  63. <mjb> ST V/Win
  64. <Carl> Smalltalk-80
  65. <automan> The maps vary in the kinds of data they represent, we want a generic
  66. means of representing them
  67. <automan> Smalltalk-80
  68. <mjb> hi rayn
  69. <aknight> We're using ST-80.
  70.  
  71. *** tcl has joined channel #Smalltalk
  72. *** Signoff: tcl (tcl)
  73.  
  74. <rayn> Hello - this is my 1st IRC.  I'm using ST V/Win
  75. <mjb> welcome rayn
  76. <Gregster> HUh?
  77. <Gregster> What's with this smalltalk thing?
  78.  
  79. <automan> We are also just looking for examples of code that do networks too.
  80. We have only been using Smalltalk for a few months and so we're always
  81. looking for good examples.
  82.  
  83. <Gregster> <----VERy VERY confused!
  84. <automan> Gregster, I was asking if anybody had examples of mathematical
  85. networks.
  86. <mjb> Gregster - ST is an object oriented programming language/environment
  87. <Gregster> LIke?
  88. <Carl> Gregster:  Do you know what the computer language Smalltalk is then you
  89. probably don't want to be here.
  90. <Gregster> See ya!
  91. <mjb> adidas
  92. *** Gregster has left channel #Smalltalk
  93.  
  94. <richard> is there a limit of 10 people to a conference, as the help messages
  95. state?
  96. <Carl> I'm going to change the topic string to something more descriptive.
  97. *** Carl has changed the topic on channel #Smalltalk to Chatting about
  98. Smalltalk, the programming language
  99. <mjb> seems like I've seen crowds larger than ten on these channels
  100. <aknight> Automan: Have you looked in the ftp archives at uiuc.
  101. <Carl> I don't think there is a limit on simultaneous users.
  102.  
  103. *** peaches has joined channel #Smalltalk
  104.  
  105. <automan> aknight: Yeah, and I found a really good file in on Directed Graphs,
  106. but nothing on networks.
  107. <mjb> hi Peaches
  108.  
  109. *** Signoff: rayn (Ping timeout)
  110. *** tcl has joined channel #Smalltalk
  111.  
  112. <automan> Has anybody gotten on ParcBench and seen anything on networks?
  113. <Carl> I'd like to chat about what people think the future direction of
  114. Smalltalk should be.
  115.  
  116. *** rayn has joined channel #Smalltalk
  117.  
  118. <richard> Hi--Richard Dellinger is VP Engineering ParcPlace.  We are actually
  119. two people here together and I am Adele Goldberg.  ParcBench does not have
  120. something on networks at this time.
  121. <richard> And specifically I would be interested in learning what Smalltalk
  122. programmers would like in the way of Team Tools.
  123. <Carl> Alan, doesn't Peter and Danny have implementations of general networks?
  124. <automan> richard: code sharing
  125. <aknight> Carl: It's possible.  I'll ask them.  Automan: perhaps you could
  126. leave me your e-mail address.
  127.  
  128. *** peaches has left channel #Smalltalk
  129. *** jsp has joined channel #Smalltalk
  130.  
  131. <mjb> Welcome Adele 
  132. <aknight> richard: We've just gotten ENVY for Smalltalk-80 and I'm very
  133. impressed.  Pricey if you're not a University, but then so is ST-80.
  134. <mjb> hi jsp 
  135. <tcl> How about debating native gui vs. cross-platform-consistent gui in st
  136.  
  137. *** jsp has left channel #Smalltalk
  138.  
  139. <richard> Of course, if you join the Partners Program the price is quite
  140. inexpensive.  The idea for the Partners Program is to provide easier access
  141. as well as future assistance in marketing any products you might create.
  142. <Carl> I think maintaining a native, Smalltalk implemented, GUI is desirable
  143. for Smalltalk
  144. <automan> tcl: I like the portability that comes with
  145. cross-platform-consistency, but I know the community that I am programming
  146. for and they want a program running on a Mac to look like a Mac program, and
  147. the same goes for the other platforms.
  148. <aknight> Carl: What do you mean by native, Smalltalk implemented.  Do you
  149. mean that Smalltalk re-implements e.g. Motif or that Smalltalk is its own
  150. thing (like pre 2.5) or just that ST has an abstracted view of the native
  151. GUI.
  152. <mjb> richard, would you define quite inexpensive?
  153. <richard> This is not an either/or issue.  Platform compliance is important,
  154. especially for people who have fairly homogeneous computing situations.  In
  155. addition, some way to augment the platform specifics where you have neat new
  156. ideas is also key.     
  157. <Carl> I mean that Smalltalk does its own thing (like pre 2.5).  Its
  158. unfortunate I think that we don't have a native Smalltalk pratform.
  159. <richard> Inexpensive is the same price as educational $350.  However we also
  160. ask members of the Partners Program to get support.  This brings the price to
  161. about $800 (comparable to Borland's C++ without support).
  162. <aknight> I didn't like the 2.5 approach.  I don't like having to choose
  163. between using Smalltalk or any of my other tools.
  164. <mjb> thax
  165. <mjb> er... thanx
  166. <Carl> Yes, on a Smalltalk platform that issue would go away.  All the tools
  167. would be in Smalltalk.
  168. <aknight> Carl: like the Momenta.
  169. <aknight> Carl: The choice is still there, it's just do I walk over to the
  170. dedicated Smalltalk machine and forsake my tools, rather than do I open up a
  171. Smalltalk window and forsake my tools.
  172. <Carl> True.  All my tools were in Smalltalk.  And I also enjoyed being to
  173. able to experiment with new UI concepts that restricting myself to the
  174. abilities of the OS's GUI often restricts what I can do. 
  175. <richard> Let me try again on Team Tools.  Do any of you work in groups of 4
  176. or more Smalltalk programmers?
  177. <mjb> not I
  178. <automan> richard: Currently we have three full-time programmers plus 2
  179. mathematicians
  180. <mjb> rayn, how are you doing with that st v? 
  181. <aknight> Technically, I work with 4 or more, but most of them are only
  182. part-time Smalltalk and many are students.  There's not a lot of
  183. coordination, something we're trying to change.
  184.  
  185. *** hanz has joined channel #Smalltalk
  186. <mjb> welcome hanz 
  187. <hanz> hi
  188. <mjb> what St are you using
  189. <mjb> ST?
  190. *** hanz has left channel #Smalltalk
  191.  
  192. <rayn> I work by myself, but manage to mis-coordinate anyway by trying to move
  193. more than one project ahead at a time.  I'm a relative newcomer to Smalltalk,
  194. so probably haven't hit the problems of really large projects.
  195. <tcl> machines with st operating systems, and all software written in
  196. smalltalk are a nice dream, but for now we should talk about the reality - we
  197. have to deal with multiple platforms. In our environment i would prefer that
  198. st work the same way on all platforms
  199. <tcl> others would prefer that st work in the native way. Can parcplace
  200. perhaps cater to BOTH needs?
  201.  
  202. *** gary has joined channel #smalltalk
  203. <mjb> welcome gary 
  204. <gary> hi
  205. <tcl> richard: yes, we have four programmers in our teamstem do 
  206. <gary> What is being discussed?
  207. <mjb> what ST system do you use? 
  208.  
  209. <richard> tcl:  yes, in fact that is the dream.  Now let's discuss reality. 
  210. We want to maintain full portability and allow you to switch between host
  211. look and feel or your own.
  212.  
  213. <gary> st80 rel 4.0t
  214. <mjb> gary, then you'll be right at home. 
  215.  
  216. *** Signoff: tcl (irc.mit.edu)
  217. *** Calvino has joined channel #Smalltalk
  218.  
  219. <richard> Switching can not mean emulation...chasing changes to the host bits
  220. is simply impossible.  So we have to devise techniques and technologies for
  221. setting look and feel policies and then calling on the host bits where the
  222. policy dictates.
  223.  
  224. <mjb> hi Calvino... 
  225. <Calvino> Hi all
  226. <mjb> you made it
  227. <Calvino> Yeah!
  228.  
  229. <aknight> richard: That sounds really interesting.  How far along the road is
  230. this? 4.1, 4.2...
  231. <richard> Not 4.1, which is in beta right now.
  232. <aknight> Any chance of a preview of differences 4.0->4.1
  233.  
  234. <Calvino> mjb: During a band rehearsal, no less.
  235. *** HaiLuv has joined channel #smalltalk
  236. *** tcl has joined channel #Smalltalk
  237. <HaiLuv> HI everyone....
  238. <mjb> welcome HaiLuv
  239. <tcl> why do you folks kkeep sighing off and on?
  240. <mjb> HaiLuv, what St system do you use? 
  241. <HaiLuv> any interesting conversation goin on here....
  242. <mjb> Smalltalk programming language is the subject here 
  243.  
  244. *** Calvino is now known as Craig
  245.  
  246. <richard> Sure.  4.0 was a big change, so there was a bug tail to chase.  Lots
  247. more documentation, especially on graphics.  Additions to the graphics
  248. package.  A special capability to call on and call from C with automatic
  249. class creation and dynamic linking.
  250.  
  251. *** dpr has joined channel #Smalltalk
  252. <HaiLuv> Well I guess I'm outa here.....don't know what that is...cya....
  253. *** HaiLuv has left channel #Smalltalk
  254. *** kmorriso has joined channel #Smalltalk
  255. <mjb> welcome to the Smalltalk programming language channel
  256.  
  257. <aknight> Richard:  Sure, document it now, after I've gone and figured it out
  258. the hard way.
  259. <richard> Continued on 4.0:  Dynamic linking is of course only on platforms
  260. that support it.  Also automatic type conversion of parameters and return
  261. values.  Some additional mechanisms to facilitate creating pluggable parts
  262. (we call these value holders).
  263.  
  264. <mjb> dpr, what St system do you use?
  265. <mjb> ST?
  266. *** dpr has left channel #Smalltalk
  267. <mjb> kmorriso?
  268. *** Bejeezel has joined channel #Smalltalk
  269. *** Signoff: kmorriso (kmorriso)
  270. *** Bejeezel has left channel #Smalltalk
  271.  
  272. <aknight> Hmm. I like the ability to call from C.  Opens up a lot of
  273. possibilities.
  274. <Craig> Back in 5
  275. <richard> Alan:  what would you do with the call backs?
  276.  
  277. <tcl> msg tcl test to myself
  278. <mjb> try "/msg whoever" 
  279. *** MikeOB has joined channel #Smalltalk
  280. *tcl* yup, i mistyped
  281. <mjb> welcome MikeOB 
  282.  
  283. <aknight> We do finite element analysis.  Big codes, much of it in FORTRAN. 
  284. The ability to call Smalltalk modules to do things would be very nice.  In
  285. particular, our remeshing code is written in Smalltalk.  Currently, that's a
  286. prototype, but if we could actually
  287. <aknight> call it directly that would be very nice.
  288. <richard> Neat.  If you can call from your Fortran to C, then you will be able
  289. to call from Fortran to Smalltalk Rel 4.1 with this external programming
  290. option.
  291. <aknight> Great.  That may yet save us from C++.
  292.  
  293. <gary> good night all.  I'm signing off.
  294. *** Signoff: gary (Leaving)nite ga       
  295.  
  296. <tcl> Aha, so you talk about rel 4.1 --- let's hear some more details of
  297. what's in it!
  298. <MikeOB> I seem to have missed something by coming in late - Rel. 4.1 is
  299. actually going to let us do callins?
  300. <tcl> is 4.1 going to be easily shrink-wrappable?
  301. <richard> tcl:  we did this...is there a log to review?
  302. <mjb> I'm loggin 
  303. <mjb> I will post log to (?)... suggestions 
  304. <aknight> One feature I'd like in ST is a profiler that would give me exact
  305. numbers for each statement (or at least method).  Probabilistic profilers are
  306. nice, but there's a lot of good uses for line-by line ones.  I know it would
  307. take forever to run, but I'd
  308. <aknight> still like it.  When I get some (hah!) spare time I may yet write
  309. it.
  310.  
  311. *** peaches has joined channel #Smalltalk
  312.  
  313. <mjb> hi peaches, welcome, to the Smalltalk programming ;anguage channel
  314. <mjb> language 
  315. *** LunarWolf has joined channel #Smalltalk
  316. <LunarWolf> merry meet
  317.  
  318. <MikeOB> I suggest that since we all must have TCP capability (or we wouldn't
  319. be here) that it makes sense to make the log available for anonymous FTP. 
  320. That'd save on Usenet bandwidth.
  321. <Craig> I can offer a site.
  322. <Carl> I'm logging the conversation right now.
  323.  
  324. *** LunarWolf has left channel #Smalltalk
  325.  
  326. <tcl> On the topic of profilers, I'd like to se two features: breakpointing
  327. (without editing to add a self halt) and inst var update/access tracing or
  328. breakpointing
  329.  
  330. *** WintrMute has joined channel #Smalltalk
  331.  
  332. <mjb> my understanding is that there is a ST archive at speedy.cs.uiuc.edu,
  333. does this ring a bell with anyone? 
  334. <aknight> I'd like to second tcl's requests.
  335. <aknight> mjb: Yes, there is an archive. Aliased to st.cs.uiuc.edu
  336. <WintrMute> whats up people?
  337.  
  338. *** Signoff: peaches (poe.acc.Virginia.EDU)
  339.  
  340. <automan> I'll third that, I have used Servios breakpoint browser and find it
  341. really useful
  342. <MikeOB> Hmmm.  The ParcPlace debugger has the ability to execute up to the
  343. carat in the current method, but it's not clear that the architecture of the
  344. VM would allow variable access trapping - sure would be nice though.
  345. <richard> good ideas, are there any other requests to improve the debugger
  346.  
  347. *** Signoff: WintrMute (Leaving) 
  348. <mjb> WinterMute, this channel is for the discussion of the Smalltalk
  349. programming
  350.  
  351. <MikeOB> One poor second I put in was a "debug" message in Object, which did
  352. nothing unless left-shift was down, then it did a halt.  A rather nice
  353. conditional halt.
  354.  
  355. <aknight> richard: In Smalltalk/V, when you set a breakpoint in a method, it
  356. stops whenever you enter a block defined in that method.  That was quite
  357. handy for quickly getting into the guts of e.g. detect:, and I miss it.
  358. <richard> Alan:  are you talking about having a breakpoint that triggers
  359. whenever a block in a method is evaluated? ...
  360.  
  361. <mjb> a few questions...
  362. <mjb> How often would like to have this meeting? weekly? bi-weekly? monthly?
  363. never again? :)
  364. <mjb> What day?> What day?
  365. <mjb>  Time of day?
  366. <mjb>  Time of day? 
  367.  
  368. <aknight> richard: Yes.  e.g. whenever a sortblock or the block argument to
  369. an iterator is entered.  In /V this always happens when you set a method
  370. breakpoint, so it's probably a semi-accidental "feature".
  371.  
  372. *Carl* I think monthly would be good.
  373. <Craig> mjb: I like late evenings (here). Then it's a decent time overseas.
  374. <tcl> here in eastern time it is 22 past midnight. Future irc sessions 
  375. should be earlier. We are losing a lot of europeans too.e is here?
  376. <mjb> where is here? 
  377. <aknight> mjb: For time of day I suggest morning Pacific time, which would
  378. allow people from Europe to participate.
  379. <automan> mjb: Bi-weekly would be nice, and so would an earlier time for
  380. those of us on the east coast.
  381.  
  382. <richard> The blocks in V are not full closures as they are in Smalltalk-80.  
  383. <aknight> richard: Yes.  To do it right you should probably be able to set
  384. breakpoints on entry to a particular closure.
  385.  
  386. <automan> mjb: Could you post to News the name of the site where the log of
  387. this discussion will be?
  388. <mjb> sure, but what's the definition of News#Smalltalk
  389. <automan> mjb: Usenet Newsfile location to comp.lang.smalltang.smalltalk
  390. <mjb> I was plan to post the file location to comp.lang.smalltalk 
  391.  
  392. <richard> We have to go now.  See you again.
  393. *** Signoff: richard (Leaving)
  394.  
  395. <MikeOB> I'd like to point out that while variable tracing is a wonderful
  396. idea - I think it's the single greatest improvement the debugger could see -
  397. that code is global but instance vars are local.  You'd have to specify
  398. which object as well as which inst var was for coming
  399.  
  400. <tcl> presumably you mean comp.lang.smalltalk
  401. <MikeOB> to be traced.!
  402. <mjb> thanx for coming!
  403.  
  404. *** peaches has joined channel #Smalltalk
  405.  
  406. <automan> mjb: Thanks. I have to go now too (meeting in the morning)
  407.  
  408. <aknight> It would also be useful to have a breakpoint when a variable is
  409. modified in any instance of a particular class.
  410. <rayn> Do any of you veterans use any automated tools for visualizing
  411. complete Smalltalk "applications"?
  412. <Carl> Only Projects
  413. <tcl> Could some of you parcplace folks post more details about 4.1 to
  414. comp.lang.smalltalk, some of us have no access to ParcBench
  415.  
  416. *** automan has left channel #Smalltalk
  417.  
  418. <Carl> I'll write it down as something to do.
  419. <MikeOB> aknight: I agree, but most variable tracing is done by putting
  420. breakpoints on a particular address (at the machine level).  This would still
  421. work in ST80 but would limit such tracing to particular objects.  To put on a
  422. general trace on a particular inst
  423. <MikeOB> var in all objects would require chasing through all of object memory
  424. setting hardware breakpoints.
  425. <aknight> MikeOB: Well, it's pretty easy to find all methods which might set a
  426. variable, but it could be a fair number of breakpoints.
  427. <MikeOB> Yes, there's nothing against it, really, but all the chasing and
  428. bookkeeping.  It would be like a mark-and-sweep GC in terms of overhead.
  429. <Craig> Arg. Can't do this and rehearse at the same time... I'll be watching
  430. comp.lang.smalltalk for the next meeting. later...
  431.  
  432. *** Signoff: Craig (Craig)
  433.  
  434. <tcl> You could do var access breakpointing by modifying (temporarily) the
  435. *methods* that already update the instvar (although this would miss
  436. instVarAt:put:
  437. <aknight> I'm willing to make anybody who uses instVarAt:put: suffer.
  438.  
  439. <tcl> well i'm gone, its too late in the east ...
  440. *** Signoff: tcl (tcl)
  441. *** Huyck has joined channel #Smalltalk
  442. *** Signoff: Huyck (Bad link?)
  443. <mjb> well...
  444. *** Signoff: MikeOB (ucsu.colorado.EDU)
  445. *** Signoff: Carl (ucsu.colorado.EDU)
  446. <aknight> I've got to get up in the morning.  So long all.
  447. *** Carl has joined channel #Smalltalk
  448. *** MikeOB has joined channel #Smalltalkback
  449. <mjb> back? 
  450. *** aknight has left channel #Smalltalk
  451. <mjb> guess it's time to put this puppy to bed, eh? 
  452. <MikeOB> I guess so.
  453.  
  454. <rayn> Are there any thoughts about what the "next" smalltalk might look like?
  455. <Carl> Gee.  I thought we'd have more to talk about.
  456.  
  457. *** Rohan has joined channel #Smalltalk
  458.  
  459. <Carl> The "Next" Smalltalk.  You mean the next generation of Smalltalk?
  460. <MikeOB> Maybe it'd go better next time if an agenda were made up and
  461. published in comp.lang.smalltalk.
  462. <rayn> I'm thinking not the next version, but yes, the successor.
  463.  
  464. *** Rohan has left channel #Smalltalk
  465.  
  466. <mjb> if we can getmore participants things might be better, still not bad for a
  467. first meeting... 
  468. <MikeOB> Well, Self is one entry in that sweepstakes.  Some folks seem to like
  469. the idea of templates over classes, as somehow more "unifying".
  470. <mjb> hard to set an agenda when you don't know who will show up...#Smalltalk
  471. <Carl> I think the next generation of Smalltalk will run natively on the
  472. machine.  As the operating system itself.  This has already been done of a
  473. few machines.
  474.  
  475. *** eggshell has joined channel #Smalltalk
  476. <eggshell> Hi, peaches!
  477.  
  478. <mjb> I will post this log to the cis -digital;k forum as well... 
  479.  
  480. <Carl> Yes, SELF is a contender.  I personally found Classes easier to deal
  481. with.
  482.  
  483. <MikeOB> mjb: Well, true, but it would give a direction to the discussion.
  484.  
  485. <eggshell> Hi, all.
  486. <mjb> it might encourage some DT people to show up as well 
  487. <rayn> Maybe an improvement, but Self seems incremental to me.  How about
  488. something that would presevre the Idea of Context in a GUI world.hi eggshell, 
  489.  
  490. *** john has joined channel #Smalltalk
  491.  
  492. <john> Hey all
  493. <mjb> hi eggshell, welcome to the Smalltalk programming language channel
  494. <mjb> welcome john
  495. <mjb> welcome john 
  496. *** carrier has joined channel #Smalltalk
  497. <john> thanks mjb
  498. <eggshell> Hi, mjb.  Thanks.
  499. <mjb> eggshell, john, what ST environments do you use? 
  500.  
  501. <MikeOB> I'd tend to believe that a future contender would have tools which
  502. would allow some level of programming interaction above the class level but
  503. below the full application level.  A few more layers in the hierarchy to make
  504. things more manageable.
  505. <Carl> I'd been thinking of something more GUI oriented.  A Smalltalk where
  506. the screen was the root for garbage collection.  Its pretty hazy though.  I
  507. think just better and more graphical programming tools would take you a long
  508. way there.
  509.  
  510. *** Alpha has joined channel #Smalltalk
  511.  
  512. <MikeOB> Sort of the way TCL and Perl have gotten very popular in making UNIX
  513. apps more manageable.
  514.  
  515. <Alpha> 'lo all
  516. <mjb> welcome to the Smalltalk programming language channel 
  517.  
  518. <rayn> I'd like to see something in a graphical environment that could help me
  519. out the way shell history does.
  520.  
  521. <Alpha> YIKES-to informed for illiterate 'ol me.
  522. <carrier> greetings all
  523. <carrier> leave #notalk
  524. *** carrier has left channel #Smalltalk
  525. *** john has left channel #Smalltalk
  526. *** Alpha has left channel #Smalltalk
  527.  
  528. <MikeOB> You know what I like?  Bots.  Independent assistants which could take
  529. high-level commands and spray out low-level messages to all and sundry.  I'm
  530. very impressed with bots.
  531. <Carl> Yes, application-level programming tools would be nice too.
  532.  
  533. *** Voyeur has joined channel #Smalltalk
  534.  
  535. <Carl> Are you talking about artifically intelligent "bots"?
  536.  
  537. <mjb> Voyeur, welcome to the Smalltalk programming language channel 
  538.  
  539. <rayn> How can the environment be set up so I can build a Really Stupid,
  540. simple Bot, like shell history.
  541.  
  542. <Voyeur> hi and thanks! 
  543.  
  544. <MikeOB> In a way.  My fiancee has had her life taken over by MUDs.  And there
  545. are folks who have written independent programs which operate in the MUD as
  546. "homunculi" - artificial players.  They use the same interface as people do,
  547. which in the
  548. <Carl> What would this Bot do?  There's no command line interface to Smalltalk
  549. (thank god).
  550. <MikeOB> case of Muds is not hard since they're text-only.
  551.  
  552. *** Voyeur has left channel #Smalltalk
  553.  
  554. <MikeOB> Well, remember that recorders and replayers of interactions have been
  555. used to launch Smalltalk demonstrations, so event strings can be managed.
  556.  
  557. *** eggshell has left channel #Smalltalk
  558. *** peaches has left channel #Smalltalk
  559.  
  560. <MikeOB> A lot of work has been done on "user agents" in the past, but I've
  561. never seen anything as capable as a MUD "bot".  I'm totally impressed by
  562. them.  They act as walking mailboxes, tourguides, etc.  If we could come up
  563. with a "bot" that acted in the
  564. <Carl> Yes, I've seen them and helped write them.  But I can't see them being
  565. terribly useful for anything other than demos and regression testing.  I
  566. think you just want better tools that make doing the common things easy.
  567. <MikeOB> capacity of, say, DWIM and Masterscope in Interlisp, we might really
  568. have something.
  569. <rayn> The problem with recorders and such is that the idea of their "context"
  570. is not strong.
  571. <Carl> What is "MUD"?
  572. <MikeOB> MUD = Multi-User Dungeon.  Sort of like IRC with manipulatable
  573. objects - "look" and "take" commands.
  574. <rayn> I think that the whole idea of the "click click click" sort of
  575. interface has to be expanded if what I want is to be built reasonably.
  576. <Carl> Hmmm....  I'd like to see this MUD.  The capacity for building these
  577. "bots" you speak of sounds interesting.  Where does "MUD"Live?
  578. <MikeOB> Well, consider context evaluators in chess programs.  One can
  579. consider that the VM, instead of just looping uselessly for input, or hanging
  580. on a semaphore, could make use of "dead" time in building suggested
  581. alternative strategies.
  582. <MikeOB> The spell checker is a really simple sort of assistant, for example.
  583. <Carl> Yes, I've implemented tools that ran in the background waiting for
  584. useless time and doing things like analyzing the classes and methods in your
  585. system finding bugs and things to warn you about.
  586. <MikeOB> For information on MUDs, send email to my fiancee,
  587. "valerie@ucsd.edu".  I don't know enough to be able to point you in the right
  588. direction.  Tell her I sent you for info.  MUDs are distributed, like IRC,
  589. but the server lives on a single machine which is
  590. <MikeOB> "home" to that particular MUD.
  591. <mjb> how do they determine "useless time"? they have a low priority?
  592. <rayn> MikeOB, alternative stratagies might be a plus, and background helpers
  593. also.  But I'm really looking for a canonical discription of the system (UI)
  594. state, that can be manipulated strongly.
  595. <rayn> How can I build a ".cshrc" that would let me look at *your* environment
  596. <MikeOB> Well, but consider that the UI is merely the control panel to the
  597. tools underneath.  If the UI is to be changed to provide new services, what
  598. are thos eservices to be?
  599. <rayn> in a way that makes most sense to *me*
  600. <Carl> Yes, using a low priority.
  601. <mjb> thannx 
  602. <Carl> MikeOB:  I don't get what you mean.  The UI IS the tools.
  603. <MikeOB> Another possibility, which we are working on here, is the notion of
  604. "wrapping", wherein pieces of a system are described in a database which
  605. enables them to be assembled automatically into larger tools.
  606. <MikeOB> Carl: I disagree.  A UI is a window to underlying capabilities, and
  607. is most functional when least noticed.  That's my philosophy, anyway.
  608. <rayn> This description sounds closer to what I'm looking for.  Could you say
  609. a little more about it?
  610. <Carl> My philosophy is direct manipulation UI.  Where from the users point of
  611. view, the UI IS the tool.  At least that is the metaphor that the programmer
  612. sweats to try and achieve.
  613. <MikeOB> We're still working it out.  Basically, one application is for a
  614. planner to make use of a planning database to formulate a path to a goal,
  615. using a resource database, then use the wrapping database to assemble the
  616. resources into a single entity which can<MikeOB> achieve the goal.
  617. <rayn> Carl, I agree with you for most cases, but sometimes I wish to describe
  618. a UI and how to use it to some robot.
  619. <Carl> MikeOB:  This wrapping database sounds conceptually deep.  You would
  620. probably have to describe a lot more about it before I could get my mind
  621. around how it works.
  622. <MikeOB> So, Carl, you are looking for better ways of achieving the metaphor
  623. of direct manipulation, and I am worrying about what the tools could be. 
  624. Complementary, I think.
  625. <MikeOB> It's very deep and our brains are frying, but we're building simple
  626. examples using FORTRAN models, RPC, message busses and a lot of what we call
  627. "C--" to glue it together.
  628. <Carl> God, I never though about have a way to describe to a software robot
  629. how to manipulate the interface.
  630. <Carl> Good heavens!  With that mismash of languages be careful you don't
  631. create a software frankenstein! 
  632. <MikeOB> Oh, I forgot the Smalltalk, the Prolog and the C++.
  633. <MikeOB> Actually, RPC saves the day.  We switched the UI from a Smalltalk
  634. prototype to a C++/Interviews package without changing a line of code
  635. elsewhere in the system.  RPC saves!
  636. <rayn> It's my prediction that just like spreadsheets made everyone
  637. programmers, and desktop publishing made everyone typesetters, that we are
  638. coming on to an age of desktop systems integraion. Similar advantages and
  639. problems.
  640. <Carl> Has anyone here seen Nicklaus Wirth's new language, Oberon?
  641. <MikeOB> It was a lot of fun doing RPC from Smalltalk before Smalltalk could
  642. really talk to the net...  But that's sort of off the topic.
  643. <MikeOB> No, tell us about Oberon.
  644. <rayn> RPC is one part of the kind of thing I'm thinking about. 
  645. <Carl> It's a pure garbage collected language like Smalltalk.  It has the most
  646. bizarre but powerful UI mechanisms I've ever seen.  It implements ALL the UI
  647. itself (like earlier Smalltalk's did).  It was quite fascinating.  There are
  648. implementations of it for
  649. <Carl> several machines.  I was using the Mac implementation.  I didn't get to
  650. play with it for a long time but what I saw was fascinating.  A fully
  651. manipulable UI with integrated support for multimedia.
  652. <rayn> Thanks.  I'll look at Oberon.
  653. <MikeOB> Where can one find more info on Oberon?  Is it a product or a project
  654. or a prototype?
  655. <Carl> I think its a project by the University that Niklaus is part of.  I got
  656. the info on it about 8 months ago from the net.  I can't remember where it
  657. was.  I wish I could find it again so I could explore it some more.
  658. <rayn> I have seen freely distributed version for the IBM PC.where get 
  659. <rayn> !archie -s oberon
  660. <mjb> where get that be obtained?
  661. <mjb> ah
  662. <Carl> Yes, the versions I saw for Suns, and Macs were freely distributed too.
  663.  
  664. *** Signoff: Carl (Bad link?)
  665. <mjb> guess he got dumped 
  666. <MikeOB> Wups.  Bye carl!
  667. *** DeadBoy has joined channel #Smalltalk
  668. <DeadBoy> HELLO????
  669. <mjb> DeadBoy, welcome to the Smalltalk programming language channel 
  670. <MikeOB> Hmmm.  If Carl doesn't make it back soon maybe this is a wrap.
  671. <mjb> yep 
  672.  
  673. <MikeOB> I love it.  Bots in Smalltalk.  What a concept.
  674. <mjb> I'd like to explore that more
  675.  
  676. <DeadBoy> SORRY WRONG CHANNEL. OOPS
  677. <DeadBoy> BYE
  678.  
  679. <mjb> software 'bots, that is 
  680. <MikeOB> I always did think little assistants running around sweeping up
  681. object space and putting things in boxes would be awfully handy.
  682. <MikeOB> One of my big pet peeves is that there are NO integrity-checking
  683. mechanisms around any more for images.
  684.  
  685. *** DeadBoy has left channel #Smalltalk
  686.  
  687. <mjb> I have a lot of image problems in st v/win
  688.  
  689. <rayn> Besides the Bots themselves, I'm hoping for something like syntax or
  690. union rules so a real Bot bueracracy can develop and be controlled. 
  691.  
  692. <mjb> the st v/pm is supposed to be a much better product 
  693.  
  694. <MikeOB> It used to be that doing an image "clone" (writing a new image file
  695. using Smalltalk code to clean things up) would do nice things, but no more. 
  696. When Xerox found all that deadwood hanging around under the Dependency class
  697. variable in Object I knew there
  698. <MikeOB> was trouble in river city.
  699.  
  700. <rayn> Where do you follow St v/win developments? CIS?
  701. <MikeOB> Enough ranting.  I should go to bed.  Catch you next meeting. 
  702. Looking forward to the log of what I had to miss!  G'night all.
  703.  
  704. <mjb> CIS mostly, BIX also
  705. <mjb> night
  706.  
  707. *** MikeOB has left channel #Smalltalk
  708.  
  709. <rayn> Thanks for the chat, folks.  I'll watch comp.lang.smalltalk for the
  710. next announcement.
  711. <rayn> bye
  712. later
  713. <mjb> later 
  714. *** Signoff: rayn (Leaving)
  715. /quit
  716. $ 
  717.